The present invention relates generally to analysis of a hardware device in connection with a computer system. More specifically, the present invention relates to analysis of internal registers within a programmable semiconductor device for purposes of debugging.
In the field of electronics, various electronic design automation (EDA) tools are useful for automating the process by which integrated circuits, multi-chip modules, boards, etc., are designed and manufactured. In particular, electronic design automation tools are useful in the design of standard integrated circuits, custom integrated circuits (e.g., ASICs), and in the design of custom configurations for programmable integrated circuits. Integrated circuits that may be programmable by a customer to produce a custom design for that customer include programmable logic devices (PLDs). Programmable logic devices refer to any integrated circuit that may be programmed to perform a desired function and include programmable logic arrays (PLAs), programmable array logic (PAL), field programmable gate arrays (FPGA), complex programmable logic devices (CPLDs), and a wide variety of other logic and memory devices that may be programmed. Often, such PLDs are designed and programmed by a design engineer using an electronic design automation tool that takes the form of a software package.
In the course of generating a design for a PLD, programming the PLD and checking its functionality on the circuit board or in the system for which it is intended, it is important to be able to debug the PLD because a design is not always perfect the first time. Before a PLD is actually programmed with an electronic design, a simulation and/or timing analysis may be used to debug the electronic design. However, once the PLD has been programmed and is operating within a working system, it is also important to be able to debug the PLD in this real-world environment.
And although a simulation may be used to debug many aspects of a PLD, it is nearly impossible to generate a simulation that will accurately exercise all of the features of the PLD on an actual circuit board operating in a complex system. For example, a simulation may not be able to provide timing characteristics that are similar to those that will actually be experienced by the PLD in a running system; e.g., simulation timing signals may be closer or farther apart than what a PLD will actually experience in a real system.
In addition to the difficulties in generating a comprehensive simulation, other circuit board variables such as temperature changes, capacitance, noise, and other factors may cause intermittent failures in a PLD that are only evident when the PLD is operating within a working system. Still further, it can be difficult to generate sufficiently varied test vectors to stress the PLD design to the point where most bugs are likely to be observed. For example, a PLD malfunction can result when the PLD is presented with stimuli that the designer did not expect, and therefore did not take into account during the design and simulation of the PLD. Such malfunctions are difficult to anticipate and must be debugged in the context of the complete system. Thus, simulation of an electronic design is useful, but usually cannot debug a PLD completely.
One approach to debugging a hardware device within a working system is to use a separate piece of hardware equipment called a logic analyzer to analyze signals present on the pins of a hardware device. (For example, the HP1670A Series Logic Analyzer from Hewlett-Packard Company.) Typically, a number of probe wires are connected manually from the logic analyzer to pins of interest on the hardware device in order to monitor signals on those pins. The logic analyzer captures and stores these signals. However, the use of an external logic analyzer to monitor pins of a hardware device has certain limitations when it comes to debugging such a device. For example, such an external logic analyzer can only connect to and monitor the external pins of the hardware device. Thus, there is no way to connect to and monitor signals that are internal to the hardware device. Unfortunately, when programming a hardware device such as a PLD, it would be useful to be able to monitor some of these internal signals in order to debug the PLD.
Although some custom hardware devices may come ready-made with some internal debugging hardware, this debugging hardware is typically hardwired to route specific internal signals and cannot be readily changed by an engineer who wishes to look at other signals. Also, with such built-in debugging it is not possible to choose any signal to monitor that the engineer desires. Further, creating an electronic design for a PLD is an iterative process that requires creative debugging by an engineer who may wish to view almost any internal signal, and who may change his mind fairly frequently in the course of debugging a PLD within a system.
As explained above, debugging discrete components on a circuit board used to be simpler in that one could look at most any input or output. Now that components are inside an integrated circuit, the ability to look at intermediate nodes and signals is inhibited. In other words, while the inputs and resultant outputs of a chip are visible, the intermediate points inside the chip are not. The overall problem then is the visibility of nodes and signals inside a chip.
Various prior art techniques have been used to solve different aspects of this problem, i.e., techniques for looking at internal signals. Actel Corporation of Sunnyvale, Calif. provides a product named SILICON EXPLORER which is an external logic analyzer with JTAG capability. This tool, however, is only able to route two internal signal lines to the outside of a chip for analysis. All internal registers are not visible. These signals are specified by the user and may not be flexibly reassigned to other signals. Furthermore, the signals are referenced via the netlists and are not identified in the original source code.
Prior art techniques that allow identification of signals by reference to a netlist can be useful; however, identifying a signal in a netlist is always a complicated and time-consuming technique. It would be far easier for a design engineer to be able to identify registers of interest in the source code directly while the engineer is creating that source code.
In the realm of processors, various tools exist for halting and dumping the contents of a processor but there is no capability for the easy identification of internal registers for analysis. With ASICs, it is known to create a built in JTAG scan chain with which to scan out information. This scan chain, though, is only for use while the device is in a test fixture and is being tested for functionality. The JTAG scan chain is not used while the device is operational in a system.
Intel Corporation of Santa Clara, Calif. uses a JTAG port to control access to specified debug registers for help in debugging a central processing unit (CPU). Because a CPU is a known design, it is known beforehand exactly how many debug registers will be needed and control is simpler. With a PLD, however, each user-implemented design will be custom; it is unknown ahead of time what that design will be and how many debug registers might be needed. Different designs will require different debug registers. Thus the straightforward technique used by Intel with a known design of a CPU would not be appropriate with a PLD.
U.S. patent application Ser. No. 08/958,435, now U.S. Pat. No. 6,182,247 referenced above discloses an advantageous apparatus and technique that allow an embedded logic analyzer to flexibly analyze internal signals of interest in an electronic design, such as within a programmable logic device (PLD). The other two above-referenced patent applications disclose a technique for embedding a separate logic analyzer in a PLD for later analysis of internal signals. These techniques, however, all impact the design in that the separate logic analyzer takes up resources in the design and may not always be the optimal solution. Thus there is room for improvement in the analysis of internal signals of a PLD for debugging purposes.
As described above, in the course of working with blocks of programmable logic it is often necessary to reveal the contents of internal registers or nodes. When programming an ASIC this can be accomplished via a scan chain connected to the JTAG port. Registers of interests are inserted in the manufacturing test scan chain and then test software can be written to reveal their contents. In programmable logic, though, the manufacturing scan chains verify the electronic design prior to the download of the end user""s design. In other words, scan chains are inserted to test the electronic design but are not part of the end user""s design, therefore end users do not have the option of inserting scan chains. An end user could of course rebuild the test logic in the programmable part of the chip but this is undesirable as it consumes both engineering development time and programmable resources. It is possible to insert an embedded logic analyzer into a programmable device (as mentioned above), but this solution is not always desirable as it performs capture into a memory buffer that uses chip resources.
What is desirable then is a technique for identifying internal registers in the source code and for automatically making these registers visible during testing or later use without significantly impacting an electronic design.
To achieve the foregoing, and in accordance with the purpose of the present invention, a debugging device and technique are disclosed that allow internal registers of a PLD to be exposed for debugging.
The present invention provides a means for a user of a programmable logic device to identify registers or nodes of interest at the source code level and then have these registers automatically inserted in a scan chain where they can be accessed by test software provided by the device manufacturer. Initially, the EDA software tool provides a means of choosing a node or register of interest from the electronic design. Next, the EDA tool connects the selected node to the JTAG scan chain and passes information to the control/post processing software about the location of the node in the scan chain. The EDA tool provides for scanning of the chain under automatic or manual control. The selected nodes are extracted from the chain and displayed in a user-specified format.
In a second embodiment of the invention, registers in encrypted blocks can be exposed. Before a particular encrypted block is sold to a user, the vendor of the block decides which registers are of importance or would be interesting to view for an engineer who is attempting to debug an electronic design. The vendor may select these registers on their own, or may select registers based upon input from its various customers. Once these registers are selected, the vendor creates a xe2x80x9cdebuggingxe2x80x9d file which is delivered to the customer along with the encrypted block. The xe2x80x9cdebuggingxe2x80x9d file contains the names of the registers (unencrypted) in the source code to which a user will have access. The user may then convey these names to the EDA tool so that they are exposed during debugging.
This embodiment of the present invention provides numerous advantages for the vendor of an encrypted block intended for an electronic design. Although a vendor wishes to allow an engineer to debug a system of which their block is a part, they do not wish to reveal their source code or go to extra efforts. Making use of this embodiment, a vendor need not change their source code to allow debugging to occur, and need not reveal their source code to the engineer user. The vendor simply creates a simple xe2x80x9cdebugging filexe2x80x9d with names of registers to be viewed and their symbolic values.